Method and apparatus of automatic method signature adaptation for dynamic web service invocation

ABSTRACT

A method (and apparatus) for adapting an input parameter,for dynamically invoke the target Web services, and for adapting output results, the method including: receiving an invocation request including an input parameter in a first format; retrieving MetaWSDL (Meta Web Service Description Language), wherein said MetaWSDL includes a universal XML (eXtended Markup Language) representation which includes semantic information of a Web service method signature; invoking a MetaWSDL processor to adapt the input parameter to a second format using the retrieved MetaWSDL; dynamically invoking the target Web services using the adapted parameter in the second format; and adapting the output result in a first format to a second format using the MetaWSDL.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention generally relates to a dynamic e-businessapplications. More particularly, this invention relates to a method andapparatus of automatic method signature adaptation for dynamic Webservice invocation.

[0003] 2. Description of the Related Art

[0004] Dynamic e-business is the dynamic adaptation of e-businessprocesses and associated systems to support changing business strategiesand tactics. It enables enterprise software to be modeled to fit therequired business processes, rather than the other way around. Whencompanies in an industry use the same enterprise software and adapttheir business processes to fit it, they inevitably conduct theirbusiness in the same way as their competitors. Flexibility ininfrastructure design allows new processes to be tried and deployed todevelop a competitive advantage by doing it differently than thecompetition. Dynamic e-business offers the same flexibility in businesspartner integration. Web services technologies enable dynamice-business. The use of Web services as programmable objects withreal-world actions is fundamental to dynamic e-business. By exposingbusiness functions as Web services that can be accessible anywhere overthe Internet, a company becomes integration-ready to jump on anyemerging opportunity with a business partner, such as to merge businessprocesses in a merger or acquisition.

[0005] Web service represents a revolution in e-business capabilities;it enables a dynamic e-business model, fosters collaboration withlayered services, and opens the doors for new business opportunities.Web Service is defined by new technologies like Simple Object AccessProtocol (SOAP), Web Services Definition Language (WSDL), Web ServiceInspection (WS-Inspection) Language (WSIL), and Universal Description,Discovery, and Integration (UDDI). These technologies include a modelfor exchanging XML information, a language for describing services, anda directory for finding new business partners, respectively. Together,they enable Web services, a powerful new paradigm for creatinge-business applications by integrating reusable software modulessupported on the Web.

[0006] SOAP defines a model for using simple request and responsemessages written in XML as the basic protocol for electroniccommunication. SOAP can be used with any transport protocol; HTTP iscurrently popular. SOAP messaging is often modeled as a platform-neutralremote procedure call (RPC) mechanism, but it can be used for theexchange of any kind of XML information. Creating clients to access theSOAP services published in UDDI, is a straightforward process if thedeveloper knows the exact interface of a Web Service. Interacting with a“document-oriented” SOAP service requires the use of lower-level SOAPAPI calls. Envelope object containing header and body to be sent mustfirst be created. Another widely used way is interacting with SOAP RPCservice.

[0007] The steps for creating a client that interacts with SOAP RPCservices are:

[0008] 1. Obtain the interface description of the SOAP service andcreate a call object. This provides one with the signatures of themethods that one wishes to invoke. Also one can look at a WSDL for theservices. The SOAP Call object is the main interface to the underlyingSOAP RPC code.

[0009] 2. Set the target URI and Set the method name that one wish toinvoke in the call object and Pass in the URN that the service uses asits identifier in its deployment descriptor.

[0010] 3. Create the necessary Parameter objects for the RPC call andset them in the Call object using setParams( ). Ensure one have the samenumber of parameters of the same types as required by the service.

[0011] 4. Execute the Call object's invoke method, retrieve the Responseobject and then extract any result or returned parameters.

[0012] In the dynamic e-business area, it is very hard to match theinput parameters and output result format in advance for the Webservices Invoke in the e-business application. Customers, marketplaces,and search engines can find the company to do business. Upon finding asuitable service provider, the company binds to the provider to begine-business transactions. To access a Web service, software only gets theWSDL description of interface information. WSDL can be provided to apotential user of a Web service for rapid integration by way of a Weblink to the file, an e-mail attachment, or from the UDDI Registrydirectly. Any companies can publish their own Web Services to anycategories in multiple UDDI registries. So the Web Services theypublished will have different service interfaces which contain differentmethod signatures. The inventors refer to these Web Services as“heterogeneous Web Services.”

[0013] At the present time, even within a specific industry domain,there are no industrial standards, nor are there unified servicedefinitions. Furthermore, neither the service definitions to be unifiednor standardized are in the near forseen future. Therefore,heterogeneous Web Services are going to be a fact of life for a while,which poses problems for dynamic e-business integration. This is becausethere is always a need for human intervention to read the WSDL for WebServices and then to correctly construct input parameters so that theymatch properly with the WSDL definitions. Such manual processes taketime and cause errors.

[0014] The need for a manual process to construct and match inputparameters for Web Services is a result of the limited informationdefined in current WSDL for Web Services interfaces, i.e. only themethod name and type of parameters, which is too generic, as well as,limited to be adequate for a program to automatically invoke the targetWeb Service. The current WSDL does not describe semantic information asto how to construct each input parameter, i.e. what kind the parameteris representing. For example, a WSDL defines an input parameter to be anumber (i.e. float type), which can be interpreted for anything. Is thenumber representing a measurement, e.g. kg, pound, foot, oz, or atemperature; or is it presenting the amount of money, which can be in USdollars or in UK pounds? Unless the desired semantic definitions areclearly specified, it would not be possible for programs to correctlyconstruct the input parameters for automatic invocation. Similarly,problems exist for the need to adapt output results to the correctformat and units. Hence, there is the need for the manual process in theconventional methods.

SUMMARY OF THE INVENTION

[0015] In view of the foregoing and other problems, drawbacks, anddisadvantages of the conventional methods and structures, an object ofthe present invention is to provide a method and apparatus of methodsignature adaptation for dynamic Web Service Invocation forheterogeneous Web Services.

[0016] Another object of the invention is to dynamically find Webservices that fit the needs of one or more parts of the businessprocess.

[0017] Yet another object of the invention is to automatically adaptinput and output parameters to eliminate the need for manual adaptation.

[0018] Still another object of the invention is to dynamically bindand/or invoke Web services by a business application that is part of abusiness process.

[0019] In a first aspect of the present invention, a method for adaptingan input parameter, the method includes receiving an invocation requestincluding an input parameter in a first format; retrieving MetaWSDLwherein said MetaWSDL is a universal XML representation which includessemantic information of a Web service method signature; and invoking aMetaWSDL processor to adapt the input parameter to a second format usingthe retrieved MetaWSDL.

[0020] In a second aspect of the present invention, a method foradapting a Web service output parameter, includes receiving an outputparameter in a first format; retrieving MetaWSDL, wherein said MetaWSDLis a universal XML representation which includes semantic information ofa Web service method signature providing the output parameter; andinvoking a MetaWSDL processor to adapt the output parameter to a secondformat using the retrieved MetaWSDL.

[0021] In a third aspect of the present invention, a method for methodsignature adapting an input parameter, the method includes parsing theinput parameter using MetaData; and invoking MetaWSDL to adapt the inputparameter.

[0022] In a fourth aspect of the present invention, a method forgenerating a MetaClient preference file in a MetaClient library forstoring information regarding a preferred set of Web services, includeslooking up UDDI registries for each preferred Web service; and storingthe location of each preferred Web service and associated method namesin a MetaClient library.

[0023] In a fifth aspect of the present invention, an apparatus formethod signature adaptation, the apparatus includes: a MetaObjectlibrary including self-describing objects defined in MetaWSDL; aMetaClient library including a preferred library of Web services; and aMetaWSDL processor adapted to process MetaWSDL, to adapt parameters andto invoke Web services dynamically, wherein said MetaWSDL is a universalXML representation which includes semantic information of Web servicesmethod signatures.

[0024] In a sixth aspect of the present invention, a Web servicedescription language for automatic method signature adaptation, includesinstructions in MetaWSDL which includes semantic information of Webservices method signatures.

[0025] In a seventh aspect of the present invention, a computer readablemedium storing instructions for adapting an input parameter which whenexecuted by one or more processors, causes the processors to performreceiving an invocation request including an input parameter in a firstformat; retrieving MetaWSDL wherein said MetaWSDL is a universal XMLrepresentation which includes semantic information of a Web servicemethod signature; and invoking a MetaWSDL processor to adapt the inputparameter to a second format using the retrieved MetaWSDL.

[0026] In an eighth aspect of the present invention, a computer readablemedium storing instructions for adapting an output parameter which whenexecuted by one or more processors, causes the processors to perform:receiving an output parameter in a first format; retrieving MetaWSDL,wherein said MetaWSDL is a universal XML representation which includessemantic information of a Web service method signature providing theoutput parameter; and invoking a MetaWSDL processor to adapt the outputparameter to a second format using the retrieved MetaWSDL.

[0027] In a ninth aspect of the present invention, a computer readablemedium storing instructions for adapting an input parameter which whenexecuted by one or more processors, causes the processors to perform:parsing the input parameter using MetaData; and using MetaWSDL to adaptthe input parameter.

[0028] In a tenth aspect of the present invention, a computer readablemedium storing instructions for generating a MetaClient preference filein a MetaClient library for storing information regarding a preferredset of Web services which when executed by one or more processors,causes the processors to perform: looking up UDDI registries for eachpreferred Web service; and storing the location of each preferred Webservice and associated method names in a MetaClient library.

[0029] In an eleventh aspect of the present invention, a computerreadable medium storing MetaData for describing semantic information forWeb services.

[0030] In a twelfth aspect of the present invention, a MetaWSDLprocessor for adapting an input parameter, the MetaWSDL processorincluding: an input adaptation device which adapts and input parameterin a first format to a second format; and a dynamic invocation devicefor invoking a Web service by providing said input parameter in saidsecond format.

[0031] In a thirteenth aspect of the present invention, a MetaWSDLprocessor for adapting an output parameter, the MetaWSDL processorincluding: a dynamic invocation device for receiving an output parameterin a first parameter from a Web service; and an output adaptation devicefor adapting said output parameter from said first parameter to a secondparameter.

[0032] Semantic information for describing and quantifying inputparameters is collectively termed “MetaData” in this invention. Forexample, MetaData definitions can be used to provide unit informationfor an input, which is important especially when conversion betweenunits are required, such as between oz and liter, foot and meter, andCelsius and Fahrenheit. Also, MetaData definitions can be used tocorrectly format the input before the Web Service is invoked withouthaving human intervention. For example, a business application receivesits input to the Web Services from a user or an external media, but theinput is in a different format than the one defined in the WSDL. Withoutmanual adaptation of the input, the Web Service cannot be correctlyinvoked nor can the desired results be obtained.

[0033] The automatic adaptation of input/output parameters issue is byfar the most difficult and the least developed area in term of utilizingWeb Services where there are toolkits and framework that facilitate bothissues 1) and 3). For issue 1), there are IBM® Web Service Toolkit(WSTK) and UDDI4J toolkits and APIs that alleviate portions of theprogramming tasks from the application; for issue 3), there is WebService Invocation Framework (WSIF) that provides dynamic Web Serviceinvocation. However, there has been no toolkit or framework forautomatically adapting input/output parameters, but it is the mostcrucial.

[0034] In order to fully realize the potentials of Web Services inDynamic e-Business, automatically adapting input/output parameters is amust. This is because the dynamic nature of Web Services where many newones can be published and old ones removed/updated at any time.Therefore, the ability to dynamically bind/invoke newlypublished/updated Web Services is essential, absolutely requires thecapability of automatically adapting input/output parameters.

[0035] Adaptation of input parameters ensure that the Web Services canbe invoked correctly while adaptation of output parameters ensure thatthe results from the Web Services are meaningful, and not just that thenumber is correct. This invention proposes a framework to adapt userinput as well as output results to the correct format and/or units thatare required to invoke the target Web Service as well as to return thecorrect results to the client. This invention can be used by allapplications that want to dynamically invoke Web Services and obtaincorrect as well as meaningful results.

[0036] To address the above mentioned e-business integration issues, anexemplary embodiment of this invention is a method and apparatus ofmethod signature adaptation for dynamic Web Service Invocation forheterogeneous Web Services, including the following components:

[0037] A) MetaWSDL—the universal XML representation to define MetaData;

[0038] B) MetaObject Library—a library of self-describing objectsdefined in MetaWSDL, including two types: 1) basic MetaObject, 2)complex/pluggable MetaObject, for handling data conversions;

[0039] C) MetaWSDL Processor—process MetaWSDL, adapt parameters andinvoke Web Services dynamically;

[0040] D) Meta Client Library—build a preferred library of Web Servicesby retrieving the latest ones; and

[0041] E) Framework to use the above components to author and publishMetaWSDLs, dynamically adapt input and output method signatures,automatically invoke Web Services for dynamic e-business integration.

[0042] An exemplary embodiment of this invention is a framework andmechanism to automate the process for dynamic Web Services invocation;it eliminates the need for manual mapping of input parameters with WSDLmethod signatures and addresses the issues of automatic adaptation forinput parameters and output results of target Web Services, whichenables dynamic Web Services invocation and obtains the intended resultsin desired units, such as money (dollars vs. yens) or measurement (feetvs. meters; oz vs. liter). This automatic adaptation is not possiblewith the current WSDL definitions. The inventive MetaWSDL, a universalXML representation, includes additional semantic information of WebServices method signatures, which are not part of the current WSDLstandards. Using both WSDL and MetaWSDL, business application softwarecan not only get the basic service interface definitions from WSDL butalso the semantic information about input and output from MetaWSDL,which enables the Web Service to be dynamically invoked. In other words,using the unit or format information about the parameters in theMetaWSDL, the parameters of the method can be correctly constructed.

[0043] An exemplary embodiment of the present invention meets thefollowing goals of the method signature adaptation for dynamic WebService invocation:

[0044] 1) Define data schema of MetaWSDL to provide additionalinformation needed for method signature adaptation;

[0045] 2) Create and publish MetaWSDL in a standard way;

[0046] 3) Define MetaObject Library, which handles data transformationfor MetaObject defined in the MetaWSDL schema;

[0047] 4) Eliminate manual process of constructing and matching inputparameters defined in the WSDL method signatures;

[0048] 5) Generate, on the client side, an up-to-date library ofpredefined, preferred Web Service names and method names for buildingcorrect invocation requests;

[0049] 6) Automate Web Service invocation; and

[0050] 7) Eliminate manual process of adapting output results to thecorrect unit or format.

BRIEF DESCRIPTION OF THE DRAWINGS

[0051] The foregoing and other purposes, aspects and advantages will bebetter understood from the following detailed description of exemplaryembodiments of the invention with reference to the drawings, in which:

[0052]FIG. 1 is a schematic representation of one exemplary embodimentof an apparatus 100 in accordance with the invention;

[0053]FIG. 2 is a schematic representation of the system architecture200 for one exemplary embodiment in accordance with the presentinvention; and

[0054]FIG. 3 is a schematic representation of an exemplary controlroutine 300 in accordance with the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS OF THE INVENTION

[0055] First, several terms and mechanism are introduced. MetaData isused as a mechanism to communicate the semantic information of the WebServices to business applications so that the applications can invokeWeb Services dynamically; MetaData is essential to solving the WebServices dynamic invocation problem in e-business integration. “Methodsignature adaptation” is the process of parsing the MetaData (orsemantic definitions of the Web Services), automatically constructingthe input parameters, as well as adapting the inputs and outputs to theproper format/units. Lastly, “MetaWSDL”, a universal XML representation,is proposed in this invention to describe MetaData; it is complementaryto the current WSDL and enriches the semantic definitions of WebServices.

[0056] Referring now to the drawings, and more particularly to FIGS.1-3, there are shown exemplary embodiments of the method and structuresaccording to the present invention.

[0057]FIG. 1 shows a schematic diagram of one exemplary embodiment ofthe invention. The apparatus 100 of the invention includes a clientserver 102 which includes a MetaWSDL processor 104 in communication witha Web browser 106, RAM 108 and a database 110, The database 110 includesa MetaObject library 112, a MetaClient library 114, a Preference file115 and a configuration file 117, The MetaWSDL processor 104 alsocommunicates with I/O 116 which, in turn, communicates with a network118, The Web browser 106 is in communication with a user I/O 120, Thenetwork 118 allows selective communication between the client server 102and Web servers 122 and 124, At least one of the Web servers 124includes a UDDI registry 126 and at least one of the Web servers 122includes a Web service 128,

[0058] Although not shown, the user I/O 120 may include any number ofdevices to interface with a user of the system 100, The user I/O 120 mayinclude, for example, a keyboard, a microphone, a pointer device such asa mouse, trackball or pen, or any other user interface device.

[0059] The organization of the following description first discussesfour components A), B), C), and D) of an exemplary embodiment of thepresent invention as listed below, followed by a description of aFramework for the system architecture, in which section five uses thefour components described before. Together, they accomplish the goal ofautomatic signature adaptation for dynamic Web service invocation inaccordance with the present invention.

A) MetaWSDL

[0060] Referring now to FIG. 2, in order to convert input parameters,MetaWSDL is created at 202 to include the semantic information, whichare embodied by MetaObjects. Each MetaObject represents a real lifeobject or notion, such as zipcode, a state name, a measurement unit(e.g. kg, ounce), or a currency (USDollar or FrenchFranc, etc.) andhandles data conversions of input parameters and output results

[0061] There are two main types of semantic information for methodsignature adaptation: 1) Specifications for input parameter adaptationmany-to-one mapping. The designated input type to the Web Service isdenoted by the keyword ‘unit’ as specified in “unit=“xsd: Kg”” where aMetaObject of ‘Kg’ embodies the actual Kilogram unit and handlesconversions from itself to other known units, such as ‘Pound’. Thekeyword ‘native unit’ denotes the unit format native to the locale asobtained by the business application. When ‘nativeunit’ is not the sameas ‘unit’, a MetaWSDL processor automatically performs a conversion,converting from ‘nativeunit’ to ‘unit’, and the mapping can be many‘nativeunits’ to one ‘unit’ before the Web Service can be successfullyinvoked.

[0062] Further, there is 2) Specifications for output result adaptationone-to-many mapping. When ‘unit’ is not the same as ‘native unit’, aMetaWSDL processor automatically performs a conversion, converting from‘unit’ to ‘native unit’, and the mapping can be one ‘unit’ to many‘native units’ before the correct result can be returned to the client.

[0063] It is important to note that MetaWSDLs are not only useful toautomate method signature adaptation using programs but also can serveas guides to application developers as manual adaption of methodsignatures.

[0064] The examples that follow describe two types of input adaptations:List 1 using basic MetaObject, List 2 using the extensive and pluggableMetaObjects; List 5 describes output adaptation using a basicMetaObject.

[0065] List 1: Example MetaWSDL for Weight Unit Adaptation Using SimpleMetaObjects. <?xml version=“1.0”?> <metaWsdl xmlns=“http://schemas.metaWsdl.org/ws/metaWsdl/”> <messageMetaname=“InShippingQuoteRequestMeta”> <partname=“meth1_inType1”unit=“xsd:Kg”/> <nativeunit name=“Pound”><conversion mapping=“none”/> </nativeunit> <nativeunit name=“Ounce”><conversion mapping=“none⇄> </nativeunit> <nativeunit name=“Ton”><conversion mapping=“none”/> </nativeunit> </messageMeta> <extension><description> This is an example extension which allows a description ofhow to create the native data and invoke a Web Service. </description></extension> </metaWsdl>

[0066] In List 1, in order to perform the method signature adaptationfor the input parameters, the above MetaWSDL is created to include thesemantic information, which introduces four MetaObjects in thedefinitions, i.e. the “kg”, “pound”, “ounce”, and “ton”, basicMetaObjects. The ‘unit’ specifies that the input for theInShippingQuoteRequest Meta Web Service is in “kg”, and the ‘nativeunit’which is the input format the application client has, and it can be“pound”, “ounce”, or “ton”, for example. Thus, a conversion is requiredto convert from the ‘nativeunit’ of “pound”, “ounce”, or “ton” to the“unit” of “kg” using the MetaObjects defined in the MetaObject Libraryfor the conversion.

[0067] For “basic” MetaObjects such as “kg’ and “pound”, “ounce”, or“ton”, no conversion mapping is specified in the MetaWSDL; a defaultmethod supported by the basic MetaObject is used to perform theconversion. Note that there is an extension tag shown in List 1, This isan optional tag which is used to carry more information about theinvocation process. For example, one can show an example native datawithin this optional tag.

[0068] List 2: Example MetaWSDL Using Complex or Extensive MetaObjectfor XML String Transformation. <?xml version=“1.0”?> <metaWsdl xmlns=“http://schemas.metaWsdl.org/ws/metaWsdl/”> <message Metaname=“InSearchUDDIRequestMeta”> <part name=“meth1_inType1”unit=“xsd:USML”/> <nativeunit name=“xsd: string”> <conversionmapping=“String2USML_MetaObject”/> </nativeunit> </messageMeta><extension> <sampleinput> OR Business %trans Private UDDIhttp://9.2.168.233:80/services/uddi/inquiryAPI Business UPS Private UDDIhttp://9.2.168.233.80/services/uddi/inquiryAPI </sample input></extension> </metaWsdl>

[0069] In List 2, in order to perform the method signature adaptationfor the input parameters, the above MetaWSDL is constructed to includethe semantic information, which introduces two complex or customMetaObjects, i.e. USML and String2USML_MetaObject, in the definition.The ‘unit’ specifies that the input for the InSearchUDDIRequestMeta WebService is “USML”, and the ‘native unit’ specifies that the applicationclient obtains is a regular string.

[0070] The conversion mapping specifies the customized MetaObject“String2USML_MetaObject”, which will be used to handle the conversionfrom the ‘nativeunit’ of “string” to the ‘unit’ “USML”, a well-formedUDDI Search Markup Language (USML) string, and then invoke a target WebService of SearchUDDI. The content included within extension tag in List2 are extracted and shown in List 3.

[0071] List 3: Example Input Obtained by Application Client for Use withMetaWSDL in List 2.

[0072] OR

[0073] Business

[0074] %trans

[0075] Private UDDI

[0076] http://9.2.168.233:80/services/uddi/inquiryAPI

[0077] Business

[0078] UPS

[0079] Private UDDI

[0080] http://9.2.168.233:80/services/uddi/inquiryAPI

[0081] In the above example of input, there are two search requestsspecified and the operator used is ‘OR’. The first request is to searchby business with ‘% trans’ as business name using the private UDDI withits URL. The second request is to search by business with ‘UPS’ asbusiness name using the private UDDI with its URL.

[0082] The input is read and transformed into the USML search script bythe String2USML_MetaObject as set forth in List 4 below.

[0083] List 4: Example USML String Converted by Extensive MetaObjectString2USML_MetaObject. <?xml version=“1.0”?> <!DOC TYPE Search SYSTEM“UDDISearch.dtd”> <Search> <ProcessId>9999</ProcessId> <Query><Source>Private UDDI</Source> <SourceURL>http://9.2.168.233:80/services/uddi/inquiryAPI </Source URL><Business Name>%trans</Business Name> <Find By>Business</Find By></Query> <Query> <Source>Private UDDI</Source> <SourceURL>http://9.2.168.233:80/services/uddi/inquiryAPI </Source URL><Business Name>UPS</Business Name> <Find By>Business</Find By> </Query><AggOperator>OR</AggOperator> </Search>

[0084] In List 5 that follows, the example shows the output resultadaptation for currency. In the example below, several basic MetaObjectsare defined, i.e. “USDollar”, “BritishPound”, “JapaneseYen”,“GermanMark”, and “FrenchFranc”. These currency units are specified as‘nativeunit’, which means the currency is from the locale or country oforigin where application client runs, and the application can receiveany one of such ‘nativeunit’s as input, the ‘unit’ denotes that the WebService output format is “USDollar”. When ‘unit’ is not the same as‘nativeunit’, MetaWSDL processor automatically performs an adaptation toconvert “USDollar” to whichever currency specified by ‘nativeunit’before returning the result back to the application.

[0085] List 5: Examplary MetaWSDL of Output Result Adaptation forCurrency. <?xml version=“1.0”?> <MetaWsdlxmlns=“http://schemas.metaWsdl.org/ws/metaWsdl/”> <messageMetaname=“OutShippingQuoteResponseMeta”> <partname=“meth1_outType”unit=“xsd: USDollar”/> <nativeunitname=“BritishPound”> <conversion mapping=“none”/> </nativeunit><nativeunit name=“JapaneseYen”> <conversion mapping=“none”/></nativeunit> <nativeunit name=“GermanMark”> <conversionmapping=“none”/> </nativeunit> <nativeunit name=“FrenchFranc”><conversion mapping=“none”/> </nativeunit> </messageMeta> </metaWsdl>

B) MetaObject Library

[0086] The purpose of the MetaObject Library is to assist in methodsignature adaptation. The MetaWSDL Processor to be discussed next usesthe MetaObject Library to perform required data conversions of inputparameters and output results. The MetaObject Library provides a set ofdata transformation objects, which can be implemented as Java Classes orother application packages to handle format/unit conversions, XMLtranslation script, plug-in modules and so on.

[0087] The MetaObject Library includes two parts: MetaObjects, and theMetaObject library configuration file.

[0088] MetaObjects—Two Types in the Library:

[0089] a) Basic MetaObjects

[0090] These data transformation objects handle simple conversions ofmeasurement, temperature, date, currency, etc; no conversion mappingneeds to be specified. For example, the units of weight may be kilogramor pound. The units of measurement can be mile or foot; oz or liter. Theunits of temperature are Celsius or Fahrenheit. Date formats includeUSDate, EuropeanDate, Week, and Day. The units of currency are USDollar,BritishPound, JapaneseYen, RMB and so forth. The address includesStreetNumber, City and Zipcode. No conversion mapping is specified forBasic MetaObject as conversion functions for these Basic MetaObjects aredefined in MetaObject themselves.

[0091] b) Custom/Pluggable MetaObjects

[0092] The MetaObject library comes with several extensible MetaObjects,and a user can define their own MetaObjects that get plugged into theMetaObject library. The conversion mapping must be specified for thecustom MetaObjects. These are MetaObjects that are customizable andpluggable. For example, Math-MetaObjects for Math Markup Language (MML)are defined to process MML when present and to perform Math calculationsusing the specified conversion.

[0093] Another example may be the USML-MetaObject for UDDI Search MarkupLanguage (USML), which is a MetaObject that constructs USML script usingthe input parameters from the application client. A Weather-MetaObjectis yet another example of a MetaObject, defined to construct aspecialized XML request for a Weather Web Service for weatherinformation. Other MetaObjects can also be defined to handle other kindsof data transformation and processing.

[0094] (c) MetaObject Library Configuration File

[0095] The purpose of the configuration file, XML or text, etc., is todefine all the MetaObjects that the MetaWSDL processor knows about. TheMetaObjects can be simple, extensible or user defined. Whenever thereare new user-defined MetaObjects, simple or custom/pluggable, they mustbe added to the configuration file for the MetaWSDL processor to be ableto invoke them at runtime. The configuration file is a mechanism thatthe custom MetaObjects can be plugged into the MetaObject library and beknown to the system without any code changes.

[0096] List 6 below shows three examples of MetaObjects: Celsius, thebasic type, USML, the complex type provided by the MetaObject Library;and the UserDefinedMetaObject, which is also a complex type but isprovided by a user and gets plugged in to the MetaObject Library.

[0097] List 6: Example MetaObject Library Configuration File <?xmlversion=“1.0”?> <meta Wsdlxmlns=“http://schemas.metaWsdl.org/ws/metaWsdl/”> <meta Libraryconfig><metaObject name=“Celsius”> <class name=“Celsius”/> <packagename=“com.ibm.UDDI.metaobjects”/> </metaObject> <metaObject name=“USML”><class name=“UDDI Search”/> <package name=“com. ibm. UDDI. BusinessExplorer”/> </metaObject> <metaObject name=“UserDefinedMetaObject”><class name=“UserDefinedClassName”/> <packagename=“my.com.userdefinedpackage”/> </metaObject> </metaLibraryconfig></metaWsdl>

C) MetaWSDL Processor

[0098] The MetaWSDL processor is the runtime central control of thisframework. Its main functions are to process MetaWSDL, to adaptparameters and to invoke Web Services dynamically. The MetaWSDLprocessor uses other components of the framework (e.g. MetaWSDL andMetaObject Library) to accomplish these functions. The details of howthe MetaWSDL Processor works are described in the System Architecturebelow and shown in FIG. 2, and include:

[0099] 1) Input Method Signature Adaptation process;

[0100] 2) Dynamic Web Service invocation using the adaptation mechanism;and

[0101] 3) Output Signature Adaptation process.

D) MetaClient Library

[0102] The MetaClient Library provides APIs to invoke an advanced UDDIsearch engine to lookup UDDI registries, retrieving a preferred set ofWeb Services. Meanwhile, it stores the location of WSDLs and the methodnames. Preferences are defined in a preference file (text or XML). TheLibrary may provide a set of default preference files. For example, thedefault preference files may be based on the locale, e.g. European,North America, South America, Africa, Asia, etc. (see examples below).An application developer can also make modifications as needed. AMetaClient Preference Library is built using the Web Service name, WSDLlocation and method name. The MetaClient Library APIs store events andupdates one or multiple UDDI registries, i.e. when a new Web Service ispublished or an existing Web Service is unpublished, the MetaClientPreference Library is updated with the latest information about WebServices. The MetaClient Library APIs should be invoked prior toinvoking the MetaWSDL processor to keep the client side information upto date. The MetaClient Library APIs provides a mechanism for theapplication to parse its input based on the MetaWSDL and, thus,simplifies the input parameter passing to the Web Services andeliminates the manual matching process.

[0103] The MetaClient library can be tailored to different applicationsby customizing the search criteria for the advanced UDDI search engine.For example, shipping planning applications may be interested intransportation Web services while financial applications may beinterested in statistical Web Services.

[0104] Furthermore, in dynamic e-business applications, an applicationclient does not always know which Web Service will be invoked at alltimes because different Web Services will be invoked based on differentbusiness rules, context or preferences. If the rules or preferences aredefined, the application client can use an advanced UDDI search Enginesuch as BE4WS (Business Explorer for Web Services) to find the correctWeb Services for a business context. For example, if the cost ofshipping an order is bigger than $100, Transportation Service A may beselected and invoked; otherwise, the Transportation Service B will beinvoked instead. Also, when the shipping order status tracking isneeded, the Tracking Web Service may be invoked.

[0105] An exemplary embodiment of the system architecture 200 of methodsignature adaptation for dynamic Web Service invocation is shown in FIG.2. There are five major processes, and they use the main componentsdescribed above, such as MetaWSDL, MetaWSDL Object library, etc.:

[0106] 1) MetaWSDL Authoring process 202,

[0107] 2) MetaWSDL publishing process 204,

[0108] 3) Input Signature Adaptation process 206,

[0109] 4) Dynamic Web Service invocation process 208 using theadaptation mechanism, and

[0110] 5) Output Signature Adaptation process 210.

[0111] 1) MetaWSDL Authoring Process:

[0112] MetaWSDL may be created using a MetaWSDL Creation Tool or a texteditor based on the WSDL of a Web Service. Some examples of MetaWSDL arelisted below to illustrate its usage.

[0113] The resulting MetaWSDL is referenced by a Web Service InspectionLanguage (WSIL) document or other documents such as a regular text file.In this invention, the inventors used WSIL document to reference theMetaWSDL. There are at least two ways to locate and retrieve theMetaWSDL:

[0114] A. Use the same file name but different file extension where bothfiles locate in the same location, and

[0115] B. Store all mapping information in one WSWL to map between eachWSDL and the complementary MetaWSDL

[0116] In this disclosure, one WSIL file is used to build the mappingbetween the WSDL and MetaWSDL.

[0117] The reason the inventors choose WSIL document (WS-inspection) forcarrying MetaWSDL (*.mws) is that the information contained within thedescription elements are extensible and customizable. These elements canbe used to point to service description documents of various forms toallow users to process only the ones that they find useful.

[0118] One example of such elements contains the “referencedNamespace”attribute, which identifies the name space to which the referenceddocument belongs. An example of the value of a “referencedNamespace”attribute for a description element that points to a WSDL document wouldbe “http://schemas.xmlsoap.org/wsdl/” (see List 5 “Example WSILdocument” below for details). The “referencedNamespace” attribute helpsthe users of WS-inspection documents to determine if the referenceddescription document is of interest to them. The optional locationattribute is used to provide the actual reference to the descriptionelement.

[0119] One extensibility element that this invention proposes to addunder the description element is to provide a pointer to MetaWSDL, whichincludes semantic information needed for method signature adaptation.The document name space specified by the referencedNamespace attributeis “http://schemas.xmlsoap.org/metawsdl/”.

[0120] In an example WSIL shown in List 7 below, two services arelisted, enclosed between the <service> and </service> tags. Each servicecontains two description elements with one having a“referencedNamespace” attribute of WSDL and one of MetaWSDL. Thelocation attributes indicate where the WSDL or MetaWSDL can beretrieved, respectively.

[0121] List 7: Sample WSIL Document <?xml version=“1.0”?> <inspectionxmlns=“http://schemas.xmlsoap.org/ws/2001/10/inspection/”> <service><description referencedNamespace=“http://schemas.xmlsoap.org/ wsdl/”location=“ http://invocation4ws1.com/services/getTemperature.wsdl”/><description referencedNamespace=“http://schemas.xmlsoap.org/metawsdl/”_(—) location=“http://invocation4ws2.com/MetaWSDLs/getTemperature.mws”/> </service><service> <description referencedNamespace=“http://schemas.xmlsoap.org/wsdl/” location=“http://invocation4ws1.com/services/be4ws.wsdl”/><description referencedNamespace=“http://schemas.xmlsoap.org/ metawsdl/”location=“http://invocation4ws2.com/MetaWSDLs/ be4ws.mws”/> </service></inspection>

[0122] One primary function provided by the WS-Inspection specificationis to define the locations where one can access WS-Inspection documents.There are two conventions that make the retrieval of WS-Inspectiondocuments easy:

[0123] A. Fixed Name WS-Inspection Documents

[0124] The fixed name for WS-Inspection documents is “inspection.wsil.”A document with this name can be placed at common entry points for a Website. For example, if the common entry point ishttp://invocation4WS.com, then the location of the WS-Inspectiondocument would be http://invocation4WS.com/inspection.wsil.

[0125] B. Linked WS-Inspection Documents

[0126] References to WS-Inspection documents may also appear withindifferent content documents, such as HTML pages.

[0127] 2) MetaWSDL Publishing Process:

[0128] The combination of the WSDL, MetaWSDL, and the Web ServiceInspection Language (WSIL) has the potential to satisfy the dynamicinvocation pattern for a Web Service request. As mentioned prior, aMetaWSDL carries all semantic information for a method signature that isnot included in the WSDL, which carries the basic method signatureinformation for a Web Service. WSIL provides links to the location ofMetaWSDLs.

[0129] Both MetaWSDLs and WSILs need to be published for the users toretrieve. There are at least two ways that they can be published:

[0130] A. Publish to a private UDDI registry 212 through the enhancedAPIs; and

[0131] B. Publish to a regular Web Server 214 which provides a hyperlinkto the published MetaWSDL and WSIL.

[0132] As usual, Web Services deployed on SOAP server are required tohave their interfaces published to a UDDI registry or to a WSIL documenton a Web Server. The hyperlink of the WSDLs are assigned by the Webserver or UDDI registry server.

[0133] Furthermore, MetaWSDL, WSIL documents and WSDL can be publishedon different servers. In addition, all MetaObjects defined by MetaWSDLschema should be stored in the MetaObject Library 216,

[0134] The next process is adaptation and invocation of a Web serviceusing the resulting MetaWSDL.

[0135] 3) Input Signature Adaptation Process:

[0136] This process includes at least the following two major steps:

[0137] A) MetaWSDL Retrieval

[0138] When an application client 218 sends an invocation request to theMetaWSDL processor 220, the method name and the WSDL location must bespecified. Then the MetaWSDL Retrieval module 222 makes a call to theWeb server 214, which hosts MetaWSDL, WSIL, and WSDL documents, toretrieve the WSIL document. From this WSIL document, based on thelocations of the WSDL, the corresponding MetaWSDL can be obtained. Thenthe MetaWSDL processor 220 will perform the method signature adaptationbased on the retrieved MetaWSDL and the WSDL.

[0139] B) Parameter Input Adaptation

[0140] The method signature adaptation includes two types ofadaptations. The first one is input parameter adaptation 206, Forexample, if there is unit or format information about the inputparameters of the method in the MetaWSDL, the input parameters can becorrectly constructed. There are at least two ways to perform theadaptation: 1) manual construction, and 2) automatic construction. Whenthe business application invokes the MetaWSDL processor proposed in thisinvention, automatic construction is always performed, which refers tothe automatic data transformation by a MetaObject in the MetaObjectLibrary 216 based on the conversion schema. For instance, if a method ofa Web Service requires a specific XML string as input, the applicationclient needs to convert a set of input strings to the required XMLstring for the method invocation. Manual construction means that theapplication developer needs to manually construct the input parametersbased on the description and guide described in MetaWSDL.

[0141] 4) Dynamic Web Service Invocation Using Adapted Input:

[0142] At this stage, the MetaWSDL processor 220 will invoke the methodrequested by the application client 218 using input parameters alreadyadapted using MetaWSDL. The invocation mechanism can be either theregular SOAP RPC client or the Web Service Invocation Framework (WSIF)client.

[0143] 5) Output Signature Adaptation Process 210:

[0144] This stage adapts the output to the correct unit or format asdefined in the MetaWSDL following the “Dynamic invocation” stepdescribed next. For example, if the unit of a stock quote from a WebService invocation is USDollar, but the desired unit for the quote foran UK application is UKPound, the quote is automatically converted toUKPound based on the MetaWSDL before returning it back to theapplication client 218.

[0145]FIG. 3 illustrates an exemplary embodiment of an integrationprocess of signature adaptation and Web Service dynamic look up andinvocation in accordance with the invention. There are at least twoscenarios for an application client to invoke a Web service:

[0146] A. The WSDL Location is Known

[0147] In this case, the overview URL of the business is given by theapplication client 218 directly. The process of signature adaptation andinvocation is described above in relation to the system architecture ofFIG. 2.

[0148] B. The WSDL Location is not Known

[0149] In this case, the application client 218 needs to submit the UDDIsearch via USML to the MetaWSDL Processor, which will look up thedesired Web Service in UDDI and then find the overview URL for thebusiness in the system architecture.

[0150] In both cases, the application client 218 must be able to specifyto the MetaWSDL Processor the desired method name to be invokeddynamically as in most cases there are multiple method names definedwithin a single WSDL. This scenario is ensured by following theMetaClient Library mechanism as described above.

[0151] The following steps describe the exemplary process flow asillustrated in FIG. 3. In step 301, the application client invokes theMetaClient Library to store a preferred set of Web sServices in theMetaClient Preference Library by looking up UDDI registries andselecting based on a preference file, or a default file withmodifications if desired, for the locale, e.g. European, North America,Asia, etc. (see details in MetaClient Library Section above). TheOverview URL is found in one of two ways (Steps 302-306): 1) If theOverview URL of the WSDL is not known, the system retrieves it, whichcan be done via a UDDI search engine, e.g. BE4WS, which parses incomingsearch requests specified as USML script, searches multiple UDDIsources, aggregates search results, and returns a target Web Service;and 2) the Overview URL of the WSDL is known before the invocation.

[0152] Retrieve MetaWSDL:

[0153] Steps 307-308, invoke MetaClient Library APIs to retrieve thecorresponding MetaWSDL for the desired WSDL found in step 302-306, Theinput is parsed. That is MetaClient Library APIs are used to parse inputbased on the MetaObjects defined in the MetaWSDL.

[0154] Invoke MetaWSDL Processor:

[0155] Step 309, the parameters in MetaObjects type, method name,locations of overview URL, MetaWSDL, and preference file (for outputadaptation), are passed.

[0156] On the Server MetaWSDL Processor Side:

[0157] In step A, the input parameter is adapted using MetaObjectLibrary. Then to invoke the Web Service in step B (Steps 310-311),either SOAP RPC client or WSIF client can be used passing the adaptedinput parameters and receive results.

[0158] In step C (Step 312) the output results are adapted usingMetaObject Library to match the correct unit/format as specified in theMetaWSDL and return the adapted output to the application client.

[0159] The following example is used to illustrate why a MetaWSDL isneeded and how to create a MetaWSDL for a real Web Service. Meanwhile,the output adaptation for get Temperature Web Service is also shown asfollows:

[0160] List 8: WSDL Input Parameters <message name=“IngetTemperature”><part name=“meth1_inType1” type=“xsd: string”/> <partname=“meth1_inType2” type=“xsd: string”/> <part name=“meth1_inType3”type=“xsd: float”/> </message>

[0161] The WSDL only defines the parameter numbers and types for thegetTemperature Web service. There is no other information associatedwith the parameters.

[0162] List 9: WSDL Output Parameters: <messagename=“OutgetTemperature”> <part name=“meth1_outType” type=“xsd: float”/></message>

[0163] The output type of getTemperature Web Service is float. But thereis no unit information or formats about this output result.

[0164] In order to perform the method signature adaptation for the inputparameters, the inventors constructed the following MetaWSDL to includethe semantic information, which introduces two MetaObjects in thedefinitions, i.e. the Zipcode and the Day Basic MetaObjects. The firstparameter is Zipcode MetaObject for the US zipcode format, and thesecond is the Day MetaObject for number of days.

[0165] The keyword ‘unit’ specifies the MetaObject ‘Zipcode’ is used inthe input to the getTemperature method. The keyword ‘nativeunit’ meanswhat kind of the native format the input obtained by the businessapplication. When ‘nativeunit’ is not the same as ‘unit’, a conversionneeds to take place to convert from the ‘nativeunit’ to ‘unit’ beforethe method can be invoked. In this case, the ‘nativeunit’ is also in thesame MetaObject ‘Zipcode’ and ‘State’ format. Therefore, no conversionis needed.

[0166] List 10: MetaWSDL for Input Parameters of Get Temperature WebService <?xml version=“1.0”?> <Meta Wsdlxmlns=“http://schemas.metaWsdl.org/ws/metaWsdl/”> <messageMetaname=“IngetTemperature”> <part name=“meth1_inType1” unit=“xsd:Zipcode”><nativeunit name=“Zipcode”> <conversion mapping=“none”/> </nativeunit></part> <part name=“meth1_inType2” unit=“xsd: State”> <nativeunitname=“State”> <conversion mapping=“none”/> </nativeunit> </part> <partname=“meth1_inType3” unit=“xsd: Day”> <nativeunit name=“Day”><conversion mapping=“none”/> </nativeunit> </part> </messageMeta> </metaWsdl>

[0167] In order to perform the method signature adaptation for theoutput result, the inventors constructed the MetaWSDL as shown in List10 above to include the semantic information, which introduces twoMetaObjects in the definitions, i.e. the Celsius and the Fahrenheitbasic MetaObjects. The ‘unit’ specifies that the output from thegetTemperature Web Service is in Fahrenheit, and the ‘nativeunit’requires it to be in Celsius. Thus, a conversion is required to convertfrom ‘unit’ of Fahrenheit to ‘nativeunit’ of Celsius. Another possibleconversion is from Fahrenheit to Kelvin if the application's native unitis Kelvin.

[0168] List 11: MetaWSDL for Output Parameters of Get Temperature WebService <?xml version=“1.0”?> <meta WSDLxmlns=“http://schemas.metaWsdl.org/ws/metaWsdl/”> <message Metaname=“Out get Temperature”> <part name=“meth1_outType”unit=“xsd:Fahrenheit”> <nativeunit name=“Celsius”> <conversion mapping=“none”/></nativeunit> <nativeunit name=“Kelvin”> <conversion mapping=“none”/></nativeunit> </part> </messageMeta> </meta WSDL>

[0169] List 12: Input Parameters Obtained by Application Client:

[0170] 555 Main Street, Mt. Kisco, N.Y., 10598, U.S.A.

[0171] 1 week

[0172] List 13: Application Client Request for Web Service Invocation:

[0173] method name: getTemperature

[0174] WSDL location:http://invocation4wsl.com/services/getTemperature.wsdl

[0175] Input parameters: a vector of Objects including two Strings(Zipcode, State) and one float (Day), i.e. “10598”, “NY”, 7.0

[0176] [see list 10 above for definitions]

[0177] The output result from the Web Service invocation is 77.0Fahrenheit. But the application client is using a different unit, forexample, Celsius. So the MetaWSDL Processor automatically converts theoriginal result with unit Fahrenheit into the required output with unitCelsius using the MetaObject defined in the MetaObject Library.

[0178] List 14: Invocation and Output Adaptation by MetaWSDL Processor// Inside MetaWSDL Processor { // Read in MetaObject libraryconfiguration and check for MetaObject type, i.e. custom or basic .....// Retrieve and parse WSIL to obtain WSDL and complementary MetaWSDL..... // Parse WSDL and MetaWSDL to obtain the following: // - methodname that matched with the target method name specified by the client// - input parameters // Parse input from application client and performrequired input adaptation based on MetaWSDL, // e.g. to obtain zipcode“10598” and state “NY”; convert “1 week” to 7 days ..... // Dynamicinvocation of target Web Service using the input parameters //constructed based on the MetaWSDL, and obtain output result. ..... //Obtain ‘unit’ and ‘nativeunit’ from MetaWSDL output parameterdefinitions. // Compare ‘unit’ (e.g., Fahrenheit) with ‘nativeunit’(e.g., Celsius). // If different, perform the conversion below: // from‘unit’ (e.g., Fahrenheit) to ‘nativeunit’ (e.g., Celsius) using theoutput result in ‘value’ variable. ..... // Invoke The convert ToStandard method from the MetaWSDL Processor library float new Value =MetaWSDL units convert To Standard (unit, nativeunit, value); ..... }..... // Inside convert To Standard // Dynamically Instantiate aMetaObject ‘unit’ at runtime using the class name ‘Fahrenheit’, parsedvia //MetaWSDL and obtained from MetaObject library configuration Invokethe method “to Standard” on the MetaObject to convert to from ‘unit’ to‘nativeunit’ // Note. every MetaObject must implement the MetaObjectinterface, which has the “to Standard( )” method float result =MetaObject to Standard (nativeunit, value); return result; } ..... classFahrenheit { public float to Celsius(float Fahrenheit) { return (float)(Fahrenheit-32)*{fraction (5/9)}; { public float to Standard (Stringnativeunit, float value) { ..... // depending on the value innativeunit, invoke the correct conversion method if (nativeunit equals(“Celsius”)) { // from Fahrenheit to Celsius return to Celsius (value);} else{// process other native unit if applicable if (nativeunit equals(“Kelvin”)) // from Fahrenheit to Kelvin return to Kelvin (value); } } }}

[0179] List 15: Output from the Above Code Snippet:

[0180] unit=Fahrenheit, value=77.0

[0181] convert to native unit Celsius, value=25.0

[0182] —or—

[0183] convert to native unit Kelvin, value=298.15

[0184] So the final result from MetaWSDL Processor is 77 (Fahrenheit).

[0185] As shown in FIGS. 1 and 2, the system for automatic methodsignature adaptation for dynamic Web service invocation is preferablyimplemented on a programmed general purpose computer. However, thesystem can also be implemented on a special purpose computer, aprogrammed microprocessor or microcontroller and peripheral integratedcircuit elements, an ASIC or other integrated circuit, a hardwiredelectonic or logic circuit such as a discrete element circuit, aprogrammable logic device or the like. In general, any device on which afinite state machine capable of implementing the method described hereincan be used to implement the method for automatic method signatureadaptation for dynamic Web service invocation.

[0186] While the invention has been described above in relation to aWSIL document it is understood that this is only one exemplaryembodiment of the invention. One of ordinary skill in the artunderstands that the invention is applicable to any other comparablemechanism to retrieve a network accessible document, like MetaWSDL,which describes the semantic information of the WSDL.

[0187] It is to also be understood that the MetaObjects described abovewhich form a portion of the invention may be co-located or dispersed.The components of the invention may be stored or processed anywherewithin an apparatus, such as a distributed process network, and stillform a part of the invention

[0188] While the invention has been described in terms of severalexemplary embodiments, those skilled in the art will recognize that theinvention can be practiced with modification within the spirit and scopeof the invention.

What is claimed is:
 1. A method for adapting an input parameter, themethod comprising: receiving an invocation request including an inputparameter in a first format; retrieving MetaWSDL (Meta Web ServiceDevelopment Language), wherein said MetaWSDL comprises a universal XML(eXtended Markup Language) representation which includes semanticinformation of a Web service method signature; and invoking a MetaWSDLprocessor to adapt the input parameter to a second format using theretrieved MetaWSDL.
 2. The method of claim 1, wherein said retrievingMetaWSDL comprises retrieving a WSIL (Web Service Inspection Language)document from a Web server.
 3. The method of claim 1, wherein saidretrieving MetaWSDL comprises invoking a MetaClient library API(Application Programming Interface).
 4. The method of claim 1, furthercomprising parsing the input parameter based on MetaObjects in theMetaWSDL after retrieving the MetaWSDL.
 5. The method of claim 1,wherein the MetaWSDL processor adapts the input parameter by referencinga MetaObject library.
 6. The method of claim 5, wherein the MetaObjectlibrary includes at least one of a simple MetaObject and a complexMetaObject.
 7. The method of claim 5, wherein the MetaObject libraryincludes user-defined MetaObjects.
 8. The method of claim 6, wherein theMetaObject library defines MetaObjects in a configuration file.
 9. Amethod for adapting a Web service output parameter, comprising:receiving an output parameter in a first format; retrieving MetaWSDL,wherein said MetaWSDL comprises a universal XML representation whichincludes semantic information of a Web service method signatureproviding the output parameter; and invoking a MetaWSDL processor toadapt the output parameter to a second format using the retrievedMetaWSDL.
 10. The method of claim 9, wherein said retrieving MetaWSDLcomprises invoking an API similar to those in a MetaClient library API.11. The method of claim 9, further comprising parsing the outputparameter based on MetaObjects in the MetaWSDL after retrieving theMetaWSDL.
 12. The method of claim 9, wherein said retrieving MetaWSDLcomprises retrieving a WSIL document from a Web server.
 13. The methodof claim 9, wherein the MetaWSDL processor adapts the output parameterby referencing a MetaObject library.
 14. A method for method signatureadapting an input parameter, the method comprising: parsing the inputparameter using MetaData; using MetaData as specified in MetaWSDL; andusing MetaWSDL to adapt the input parameter.
 15. The method of claim 14,wherein said MetaData comprises semantic information.
 16. The method ofclaim 14, wherein said MetaWSDL comprises a universal XML representationto define MetaData.
 17. The method of claim 14, further comprisinginvoking a Web service on a Web server using the adapted inputparameter.
 18. A method for generating a MetaClient preference file in aMetaClient library for storing information regarding a preferred set ofWeb services, comprising: looking up UDDI registries for each preferredWeb service; and storing the location of each preferred Web service andassociated method names in a MetaClient library.
 19. An apparatus formethod signature adaptation, the apparatus comprising: a MetaObjectlibrary including self-describing objects defined in MetaWSDL; aMetaClient library including a preferred library of Web services; and aMetaWSDL processor adapted to process MetaWSDL, to adapt parameters andto invoke Web services dynamically, wherein said MetaWSDL comprises auniversal XML representation which includes semantic information of Webservices method signatures.
 20. The apparatus of claim 19, wherein saidself-describing objects comprise at least one of a basic MetaObject anda complex/pluggable MetaObject.
 21. The apparatus of claim 20, whereinsaid MetaObject represents one of a measurement unit, a monetary unit, azipcode, and a State name.
 22. The apparatus of claim 19, wherein saidMetaObject library includes specifications for input parameteradaptation and specifications for output result adaptation.
 23. Theapparatus of claim 20, wherein said basic MetaObject handles a simpleunit conversion.
 24. The apparatus of claim 20, wherein saidcomplex/pluggable MetaObject comprises an extensible MetaObject which iscustomizable and pluggable.
 25. The apparatus of claim 19, wherein theMetaObject library comprises a MetaObject library configuration file.26. The apparatus of claim 19, wherein the MetaClient library comprisesAPIs to invoke a UDDI search engine to retrieve a preferred set of Webservices.
 27. The apparatus of claim 19, wherein the MetaClient librarystores the location of WSDLs and Web service names.
 28. A MetaWSDL forautomatic method signature adaptation, comprising semantic informationof Web services method signatures.
 29. A computer readable mediumstoring instructions for adapting an input parameter which when executedby at least one processor, causes the processor to perform: receiving aninvocation request including an input parameter in a first format;retrieving MetaWSDL, wherein said MetaWSDL comprises a universal XMLrepresentation which includes semantic information of a Web servicemethod signature; and invoking a MetaWSDL processor to adapt the inputparameter to a second format using the retrieved MetaWSDL.
 30. Acomputer readable medium storing instructions for adapting an outputparameter which when executed by at least one processor, causes theprocessor to perform: receiving an output parameter in a first format;retrieving MetaWSDL, wherein said MetaWSDL comprises a universal XMLrepresentation which includes semantic information of a Web servicemethod signature providing the output parameter; and invoking a MetaWSDLprocessor to adapt the output parameter to a second format using theretrieved MetaWSDL.
 31. A computer readable medium storing instructionsfor adapting an input parameter which when executed by at least oneprocessor, causes the processor to perform: parsing the input parameterusing MetaData using MetaData as specified in MetaWSDL; and usingMetaWSDL to adapt the input parameter.
 32. A computer readable mediumstoring instructions for generating a MetaClient preference file in aMetaClient library for storing information regarding a preferred set ofWeb services which when executed by one or more processors, causes theprocessors to perform: looking up UDDI registries for each preferred Webservice; and storing the location of each preferred Web service andassociated method names in a MetaClient library.
 33. A computer readablemedium storing MetaData for describing semantic information for Webservice complementary to an SDL.
 34. A MetaWSDL Processor for adaptingan input parameter, the MetaWSDL processor comprising: an inputadaptation device which adapts and input parameter in a first format toa second format; and a dynamic invocation device for invoking a Webservice by providing said input parameter in said second format.
 35. AMetaWSDL processor for adapting an output parameter, the MetaWSDLprocessor comprising: a dynamic invocation device for receiving anoutput parameter in a first parameter from a Web service; and an outputadaptation device for adapting said output parameter from said firstparameter to a second parameter.